歷史背景

Firebase AI Logic 在 2025 年以及 2026 年的大部分時間裡都不支援文字轉語音（Text-to-Speech），因此我舊的專案建立了一個 Firebase Cloud Function 來呼叫 Gemini API，以便將文字轉換為語音。接著，Angular 應用程式呼叫該雲端函式以取得 WAV 格式的原始二進位資料，並將其指派給 HTML audio 元素的 src 屬性。使用者點擊該元素的播放按鈕即可聆聽語音。

我曾請 Gemini CLI 使用 TailwindCSS V4 類別來設定元件樣式，因此外觀看起來不算太糟。然而，它缺乏完整的設計系統（Design System）。

該專案分為兩個部分：一個 Angular 用戶端和一些 Firebase Cloud Functions。由於缺乏完善的 DevOps 背景，我無法將它們部署到雲端，只能在 localhost 本地端進行測試。

目標

8 月份時，Firebase AI Logic 終於支援了文字轉語音，時間點恰到好處。

我可以透過一個全新的（greenfield）Angular 專案重新打造它，並利用 AI 來解決我的許多痛點：

• 運用技能（Skills）為新產品需求建立 PRD（產品需求文件）與不可逆架構決策建立 ADR（架構決策記錄）
• 運用 AI 與 Angular 技能在 Angular 中實現 PWA 與 A11y（無障礙輔助功能）
• 運用 AI 生成 Node.js 指令碼來管理 Firebase 基礎架構，以減少情境切換（context switching），並防止因推播公開的 Firebase API 金鑰而觸發 GitHub 的誤報警告
• 運用 AI 定義設計權杖（design tokens），並呼叫 Stitch MCP 伺服器中的工具來建立專案、建立新畫面以及編輯畫面
• 採用測試驅動設計（TDD）以確保程式碼變更後的正確性
• 在重要的檢查點（checkpoints）後套用技能來改進程式碼庫（codebase）設計
• 指示 Chrome DevTool MCP 伺服器執行 Lighthouse 稽核與效能追蹤等操作，以在 Antigravity-CLI 中收集效能指標。我不必立即解決效能問題，但可以詢問 AI 為何分數偏低以及修復方案為何
• 當應用程式為純用戶端（client-side only）時，部署變得非常簡單。我可以透過 Firebase App Hosting 自動化正式環境部署。在將程式碼推送到遠端 GitHub 儲存庫後，變更就會自動部署到正式環境。

首先，我建立了一個新的 Angular 專案，並選擇了 CSS 和 TailwindCSS 函式庫。

ng new ng-firebase-tts

Angular 編譯器安裝了依賴項，並至少為 TailwindCSS 和 Prettier 建立了設定檔鷹架。

在 .prettierrc 中，我喜歡將 printWidth 從 100 增加到 120，並在 package.json 中新增一個 format 指令稿來格式化工作區中的檔案。

{
  "printWidth": 120,
  "singleQuote": true,
  "trailingComma": "all",
  "semi": true,
  "overrides": [
    {
      "files": "*.html",
      "options": {
        "parser": "angular"
      }
    }
  ]
}

"scripts": {
    "ng": "ng",
    "start": "ng serve",
    "format": "prettier --write \"**/*.{ts,js,mjs,json,html}\""
  },

第二步，我安裝了額外的開發依賴項，並建構了一個工作流程（pipeline）來自動化維護程式碼品質、修正格式並標準化 commit 訊息。

新增 ESLint

cd ng-firebsae-tts
ng add angular-eslint

angular-eslint 原理圖（schematics）安裝了 eslint 並為我生成了 eslint.config.js。接著，我提示 AI 將 eslint.config.js 遷移至 eslint.config.mjs，這樣我就可以使用 eslint-plugin-unicorn 依賴項中的 unicorn/prefer-switch 規則。

cd ng-firebase-tts
agy

提示詞（Prompt）：

Please migrate @eslint.config.js to @eslint.config.mjs

之後，我安裝了 eslint-plugin-unicorn、lintstaged、husky、@commitlint/cli 以及 @commitlint/config-conventional：

npm i --save-exact --save-dev eslint-plugin-unicorn lintstaged husky @commitlint/cli@commitlint/cli

接著，我更新了 tsconfig.json 以新增 resolveJsonModule 和 paths。resolveJsonModule: true 允許 Angular 程式碼直接讀取 JSON 檔案中的值。新增 paths 後，import 路徑的檔案路徑就可以改用 @/ 開頭，而非相對路徑。

{
    "compilerOptions": {
        "resolveJsonModule": true,
        "paths": {
            "@/*": ["./src/app/*"],
            "@/public/*": ["./public/*"]
        }
    }
}

您可以在 ESLint 設定檔 中找到這些 ESLint 規則。

一些有代表性的規則：

新增程式碼品質自動化

在完成 ESLint 遷移後，顯而易見的選擇是為 commitlint 與 lintstaged 建立 mjs 設定檔。接著，新增 pre-commit 和 commit-msg husky 鉤子（hooks）。

新增設定檔

commitlint.config.mjs 和 lint-staged.config.mjs 都非常簡短。

最精簡的 commitlint.config.mjs 只有 3 行。

export default {
  extends: ['@commitlint/config-conventional'],
};

lint-staged.config.js 可修復 ESLint 錯誤並格式化暫存（staged）檔案。

export default {
  '*.{ts,js,mjs,html}': ['eslint --fix', 'prettier --write'],
  '*.{json,css,md}': ['prettier --write'],
};

最後一步是開啟終端機以初始化 husky 並新增鉤子。

新增 Husky 鉤子

npx husky init

該指令會建立一個 .husky/pre-commit 檔案。開啟它並刪除所有內容。

npx --no lint-staged

建立 commitlint 鉤子：

echo "npx --no -- commitlint --edit \$1" > .husky/commit-msg

第 2 天到此結束。安裝 eslint、prettier、lint-staged、husky 和 commitlint 等開發依賴項本身或許平淡無奇，但在開啟一個新專案時，這是一個至關重要的階段。這正是具備企業級水準的系統與脆弱原型之間的劃時代分水嶺。

相關資源：
Angular ESLint
Commitlint
Husky
Lintstaged
ESLint
eslint-plugin-unicorn
設定 commit-msg 鉤子